Documento-mestre de Estruturação do Projeto Natter Gestão 360

1. Sumário executivo

O Grupo Natter é um ecossistema empresarial composto por quatro empresas independentes: Natter, responsável pela operação agrícola; Saciatta, responsável pela criação de peixes, frigorífico e exportação; Ambios, dedicada a fertilizantes e insumos agrícolas; e Natter Administração, responsável pela gestão corporativa do grupo. Embora as empresas possuam operações diferentes, elas compartilham o mesmo proprietário e precisarão utilizar uma plataforma comum, com separação de dados por empresa e uma visão consolidada de portfólio.

O desafio relatado não é apenas criar um sistema de RH, controle de ponto ou aplicativo de tarefas. O desafio é construir uma camada de gestão da execução, capaz de conectar pessoas, jornada, tarefas, máquinas, ocorrências, gestores, metas, avaliações, ideias, dados de origem e remuneração variável. Hoje, parte do processo está distribuída entre Excel, conversas, sistemas independentes e decisões que dependem de memória ou consolidação manual.

A tese de produto é que o Grupo Natter pode evoluir para um sistema operacional de gestão de pessoas e performance operacional, no qual cada empresa mantenha sua identidade e suas regras, mas compartilhe um núcleo comum de governança, dados, comunicação e inteligência. A plataforma deve permitir que a diretoria alterne entre empresas, compare indicadores compatíveis e identifique riscos, sem eliminar o contexto específico de cada negócio.

A implantação será pensada em duas camadas. A primeira é o núcleo-base, desenvolvido e implantado em uma empresa de referência. A segunda é composta por pacotes adicionais de implantação para as demais empresas, reaproveitando o núcleo, mas respeitando o saneamento, as permissões, os indicadores e os fluxos próprios de cada operação. A premissa informada para orçamento é um esforço-base de aproximadamente 8 a 12 meses e um esforço adicional de 3 a 4 meses por empresa, sem transformar esses números em prazos funcionais deste documento.

2. Como ler este documento

A leitura começa pelo que acontece hoje, antes de qualquer tela ou tecnologia. Em seguida, os Jobs To Be Done traduzem o trabalho real das pessoas e evidenciam o que elas tentam realizar. Depois, a visão 360 apresenta a proposta de ecossistema, os módulos, os agentes, os painéis e as integrações. Por fim, as hipóteses, as ondas de implantação e a ponte para os PRDs organizam como a ideia poderá evoluir para um produto construível.

2.1 Artefatos visuais do documento

3. Contexto do ecossistema empresarial

O grupo atua em negócios agroindustriais complementares, mas com naturezas operacionais distintas. A Natter concentra o desafio agrícola de grande escala, com extensas áreas de cultivo, centenas de colaboradores, máquinas e operações dependentes de clima, janela, manutenção e produtividade. A Saciatta combina criação de peixes, represas, frigorífico, qualidade, produção e exportação. A Ambios transforma subprodutos e outros insumos em fertilizantes e produtos para produtores. A Natter Administração coordena serviços corporativos e gestão compartilhada.

Cada empresa possui seus próprios objetivos e indicadores, mas o proprietário precisa enxergar o conjunto. O sistema, portanto, deve trabalhar com dois movimentos simultâneos: isolamento operacional por empresa e consolidação gerencial no nível do grupo. O mesmo colaborador não deve ser misturado entre empresas sem vínculo formal; ao mesmo tempo, a diretoria deve conseguir comparar pontualidade, cumprimento de metas, desafios, horas extras e tendências quando as métricas forem realmente equivalentes.

4. Evidências observadas nos materiais

A planilha de funções e quantitativos representa 732 colaboradores, distribuídos em 12 entidades ou unidades, 176 combinações de entidade e seção e 203 funções distintas.¹ As maiores concentrações estão na Fazenda Santa Terezinha, com 141 colaboradores; no Frigorífico, com 140; e na Matriz Corporativa, com 112. Essas três estruturas somam 393 colaboradores, aproximadamente 53,7% do quadro representado.¹

A planilha de remuneração variável organiza a lógica em quatro blocos: resultados do negócio; performance operacional; indicadores comportamentais/Valores em Ação; e saúde e segurança do trabalho.² O material reúne métricas agrícolas, corporativas, de piscicultura, da Ambios, de pecuária, além de formulário e comitê avaliador. As métricas misturam periodicidades, metas, pesos, prazos, indicadores de qualidade, produtividade, estoque, segurança, conformidade e comportamento.

A auditoria técnica encontrou 366 fórmulas no arquivo de remuneração variável. Existe uma referência explicitamente quebrada com #REF! em FORMULARIO!I8, além de células derivadas com #REF! e #N/A.² Essa evidência não invalida a lógica de negócio, mas demonstra que a futura solução não deve simplesmente reproduzir fórmulas escondidas. Ela deverá converter as regras em um catálogo versionado, com fonte, unidade, meta, peso, vigência, responsável, evidência, exceção e memória de cálculo.

5. Problema central

O problema é composto por cinco tensões. A diretoria quer visão consolidada, mas a operação precisa de contexto local. O grupo quer comparar pessoas e empresas, mas funções e ambientes não são idênticos. A empresa quer controlar custo e produtividade, mas não pode transformar ausência de telemetria ou um evento isolado em culpa automática. O RH quer distribuir bônus, mas precisa confiar nas regras e nos dados. Os gestores precisam responder e avaliar, mas não podem ser soterrados por formulários complexos.

6. O que o sistema precisa mudar

O produto deverá substituir a lógica “cada problema possui uma planilha ou conversa” por um ciclo em que todo objeto relevante tenha identidade, responsável, estado e evidência. Uma tarefa deverá ter descrição, resultado esperado, responsável e prazo configurável. Uma ocorrência deverá ter contexto, severidade, responsável e ação. Uma hora extra deverá ter origem, justificativa, decisão e histórico. Uma métrica deverá ter fórmula, fonte, meta, peso, vigência e aprovador. Uma nota deverá ter critério, evidência e possibilidade de revisão.

7. JTBD 1 — Diretoria e proprietário: governar o portfólio com confiança

Executor do trabalho

Rafael Bortoli, CEO, proprietário e diretoria do grupo.

Trabalho-a-Ser-Feito Funcional Principal

Governar quatro empresas independentes, entendendo onde há desempenho, risco, desperdício, atraso, horas extras, quebra de máquinas, baixa adesão ou oportunidade de melhoria, para tomar decisões e aprovar a remuneração variável com confiança.

Trabalhos de consumo

Quando preciso decidir sobre bônus, investimentos, mudanças de gestão ou prioridades, quero sair de informações isoladas e receber uma leitura consolidada por empresa, unidade, área, gestor e colaborador, com evidências e alertas sobre a qualidade do dado.

Trabalho relacionado

Acompanhar resultados de negócio, tendências operacionais, custos, produtividade, segurança, pessoas, desafios e clima; comparar empresas quando as métricas forem equivalentes; questionar variações relevantes; e escolher onde a diretoria deve intervir.

Trabalho emocional

Sentir que possui controle do grupo sem precisar controlar cada operação manualmente. Ter confiança de que uma decisão de bônus não foi construída sobre uma planilha frágil ou uma percepção isolada. Ser informado sobre problemas antes que eles se tornem perdas maiores.

Jornada atual resumida

A diretoria recebe informações por relatórios, planilhas, conversas e escalonamentos. Quando há dúvida, solicita explicações a RH, Administração, gestores ou operação. A resposta depende da velocidade de consolidação e da qualidade da informação disponível.

Resultados desejados

Oportunidade de produto

Criar o Centro de Visão do Grupo, com cards de portfólio, filtros, comparativos autorizados, alertas, leitura narrativa e acesso à evidência. O sistema deve separar “o que aconteceu”, “o que pode explicar”, “o que precisa de decisão” e “qual é a recomendação”.

8. JTBD 2 — Gestor agrícola: conduzir o turno e proteger a operação

Executor do trabalho

Gestor agrícola, gerente de fazenda, coordenador de operação ou responsável por equipes de campo.

Trabalho-a-Ser-Feito Funcional Principal

Conduzir pessoas, máquinas e tarefas durante o turno, mantendo a operação dentro do planejamento, identificando desvios e agindo antes que uma falha de equipamento, atraso ou baixa produtividade comprometa a janela, o custo ou o resultado.

Trabalhos de consumo

Quando o turno estiver em andamento, quero saber o que estava planejado, o que foi executado, o que está atrasado, qual máquina está parada, qual ocorrência precisa de decisão e qual pessoa ou equipe aguarda orientação.

Trabalho relacionado

Planejar atividades, distribuir pessoas, acompanhar manutenção, garantir segurança, interpretar condições de campo, conversar com supervisores, validar horas extras, corrigir prioridades e prestar contas à Administração.

Trabalho emocional

Sentir que está à frente da operação e não apenas reagindo a problemas. Ser reconhecido por preservar produtividade, segurança, equipamento e equipe. Ter condições de orientar sem depender de informações incompletas.

Jornada atual resumida

O gestor acompanha o turno por mensagens, ligações, sistemas operacionais e observação direta. Muitas decisões ficam registradas apenas em conversas. Quando uma máquina quebra ou um trabalho atrasa, a causa, o responsável e a ação podem não formar uma memória única.

Resultados desejados

Oportunidade de produto

Criar o Cockpit do Gestor, com visão do turno, tarefas, pessoas, máquinas, ocorrências, extras, riscos e check-in conversacional. A IA deve perguntar o mínimo necessário e gerar registros revisáveis, sem transformar a conversa em decisão automática.

9. JTBD 3 — RH e Administração: fechar o ciclo de pessoas e RV

Executor do trabalho

Equipe de RH, Administração, Controladoria e responsáveis pelos ciclos de avaliação e remuneração variável.

Trabalho-a-Ser-Feito Funcional Principal

Consolidar pessoas, vínculos, jornada, metas, avaliações, ocorrências e regras de remuneração variável para conduzir ciclos confiáveis, reproduzíveis, explicáveis e aprovados pelas áreas e pela diretoria.

Trabalhos de consumo

Quando iniciar ou fechar um ciclo, quero saber quem está elegível, quais fontes foram atualizadas, quais dados faltam, quais regras estão vigentes, quais áreas precisam validar e como cada parcela foi formada.

Trabalho relacionado

Saneiar cadastro, acompanhar admissões e desligamentos, administrar políticas, conduzir comitês, responder dúvidas, tratar contestações, manter evidências, gerar relatórios e preparar dados para o processo oficial de folha ou pagamento.

Trabalho emocional

Sentir segurança de que não está distribuindo bônus com base em erro de fórmula, pressão de última hora ou percepção sem evidência. Ser visto como guardião de um processo justo e não como responsável por uma planilha que ninguém consegue explicar.

Jornada atual resumida

O RH depende de arquivos, fórmulas, áreas e gestores. Uma alteração de regra pode afetar diversas células. Dúvidas sobre nota, peso, prazo ou elegibilidade exigem reconstrução manual do cálculo.

Resultados desejados

Oportunidade de produto

Criar o Orquestrador de Ciclos, reunindo fontes, população, indicadores, avaliações, pesos, fundo, cálculo, simulação, aprovação, congelamento, exportação e contestação.

10. JTBD 4 — Supervisor e manutenção: aprender com falhas e ocorrências

Executor do trabalho

Supervisor de operação, líder de turno, manutenção, PCM, segurança e responsáveis pela tratativa.

Trabalho-a-Ser-Feito Funcional Principal

Registrar uma quebra, parada, risco ou desvio com contexto suficiente para recuperar a operação, identificar a causa, atribuir a ação correta e evitar reincidência.

Trabalhos de consumo

Quando uma máquina ou processo sair do padrão, quero registrar rapidamente local, equipamento, atividade, pessoa relacionada, descrição, evidência e impacto, para que a tratativa comece sem esperar uma consolidação posterior.

Trabalho relacionado

Fazer diagnóstico, abrir ou relacionar ordem de serviço, acionar peças e equipes, verificar segurança, acompanhar prazo, testar retorno à operação e alimentar histórico do equipamento.

Trabalho emocional

Sentir que a ocorrência gera melhoria e não apenas culpa. Ter reconhecimento quando evita uma reincidência. Conseguir demonstrar que uma falha veio de manutenção, planejamento, condição de campo, processo ou treinamento.

Resultados desejados

Oportunidade de produto

Criar o Centro de Ocorrências e Confiabilidade, integrado a equipamentos, pessoas, atividades, telemetria, manutenção e indicadores de segurança.

11. JTBD 5 — Colaborador e operador: executar, justificar e ser ouvido

Executor do trabalho

Colaborador administrativo, operador de máquina, equipe de campo, produção, frigorífico, piscicultura, Ambios ou Administração.

Trabalho-a-Ser-Feito Funcional Principal

Executar o trabalho com clareza, registrar o que aconteceu, justificar situações fora da jornada, relatar problemas ou ideias e receber uma avaliação e um reconhecimento que reflitam sua realidade.

Trabalhos de consumo

Quando concluir uma atividade, fizer hora extra, encontrar um risco, tiver uma sugestão ou receber uma avaliação, quero usar um canal simples, saber o status do registro e entender como a informação será utilizada.

Trabalho relacionado

Consultar escala e tarefas, responder mensagens, anexar evidências, acompanhar feedback, participar de pesquisas, solicitar correção de cadastro e contestar registros que considere incorretos.

Trabalho emocional

Sentir respeito, escuta e justiça. Não ser tratado como culpado por um dado incompleto. Ter oportunidade de mostrar uma boa ideia, uma melhoria ou um esforço que não aparece nos relatórios tradicionais.

Resultados desejados

Oportunidade de produto

Criar a Jornada do Colaborador, com portal responsivo, aplicativo e WhatsApp, sempre com finalidade clara, linguagem simples, retorno e política de identidade.

12. Matriz de dores e oportunidades

13. Mensagem central

O Natter Gestão 360 é uma plataforma de gestão da execução e das pessoas. Ela conecta as quatro empresas, mas não as mistura. Cada negócio preserva sua estrutura e suas regras; o grupo recebe uma visão de portfólio, comparativos responsáveis e governança comum.

A plataforma começa na realidade operacional: uma pessoa, uma equipe, uma tarefa, uma máquina, uma jornada, uma ocorrência ou uma meta. A partir disso, cria um ciclo de gestão que chega à diretoria por meio de indicadores, exceções, explicações e simulações. A IA não substitui esse ciclo; ela reduz o esforço para alimentá-lo e interpretá-lo.

14. Princípios de produto

15. Camadas do ecossistema

16. Componentes principais do produto

17. Visão de portfólio e comparativos

O proprietário deverá ter uma visão de portfólio com seletor de grupo, empresa, unidade, área e período. A navegação deve permitir alternar entre uma visão consolidada e uma visão individual de cada empresa. O comparativo não será um ranking automático de tudo; será uma análise condicionada à compatibilidade das métricas.

18. Macrofuncionamento do ciclo de gestão

O produto será alimentado por fontes e pessoas. O Senior fornecerá a base prioritária de colaboradores, vínculos e ponto, conforme os módulos e APIs liberados. As fontes operacionais fornecerão máquinas, atividades, produção, paradas e outros eventos quando disponíveis. Gestores e colaboradores complementarão contexto, justificativas, avaliações e evidências.

O sistema organiza esses sinais em objetos de negócio, identifica pendências e oferece ações. Uma hora extra gera uma solicitação; uma quebra gera uma ocorrência; uma tarefa atrasada gera uma exceção; uma avaliação gera um plano; uma ideia gera triagem; uma métrica sem fonte bloqueia publicação; um ciclo de RV gera simulação e aprovação.

O valor do produto está no ciclo completo: captar sinal → organizar contexto → solicitar confirmação → registrar decisão → medir resultado → aprender e agir novamente.

19. Agentes e capacidades de IA

A IA deverá operar como uma camada de apoio, separada do motor de regras e da autorização humana. Ela pode fazer perguntas curtas, resumir pendências, classificar ocorrências e sugerir próximos passos. Não deve aprovar hora extra, atribuir nota final, decidir punição ou liberar pagamento de RV sozinha.

A plataforma deverá armazenar a pergunta, a resposta original, a interpretação gerada, os dados utilizados, o usuário que confirmou e a ação resultante. Em ambientes de campo, áudio poderá ser transcrito, mas o colaborador deverá saber quando a transcrição e a interpretação estiverem sendo utilizadas.

20. Canais e experiência

O portal web será o centro de gestão para diretoria, RH, Administração, gestores e comitês. O aplicativo móvel ou portal responsivo será priorizado para supervisores, líderes e colaboradores de campo. O WhatsApp será um braço conversacional de apoio, especialmente para alertas, justificativas, check-ins, escuta e confirmações simples.

Antes de habilitar ações transacionais, o produto deverá publicar uma política inicial de WhatsApp com finalidade, consentimento, identificação do usuário, tipos de mensagem, retenção do histórico, uso de áudio e transcrição, tratamento de dados sensíveis, opt-out, escalonamento humano, contestação e auditoria. No primeiro estágio, o canal poderá operar para notificações, perguntas e respostas estruturadas. Aprovação de hora extra, alteração cadastral ou decisão de PLR somente poderá ocorrer com autenticação, confirmação explícita e trilha suficiente. O provedor oficial permanece uma decisão de arquitetura a ser validada.

21. Fluxo 1 — Pessoa, estrutura e acesso

22. Fluxo 2 — Jornada, hora extra e execução

23. Fluxo 3 — Quebra, parada e aprendizado operacional

24. Fluxo 4 — Gestão semanal do gestor

25. Fluxo 5 — Avaliação, comitê e desenvolvimento

26. Fluxo 6 — PLR anual por empresa e remuneração variável

O produto deve tratar a PLR como um ciclo anual governado por empresa. O valor de R$ 10 milhões foi apenas uma referência ilustrativa e não deve ser pré-configurado como fundo oficial. Cada empresa deverá possuir seu próprio ciclo e seu próprio valor aprovado, com possibilidade de visão consolidada pela diretoria. A apuração parte do exercício fiscal encerrado do ano anterior e do fechamento oficial desse exercício.

A distribuição é individual por colaborador. Entretanto, o resultado final pode ser influenciado por camadas organizacionais, empresariais, de unidade, área, equipe e indivíduo. A memória de cálculo precisa mostrar a contribuição de cada camada sem esconder o resultado individual.

Modelo de cálculo de referência

O cálculo deve ser configurável por empresa e por ciclo anual. O exercício fiscal de referência e o fechamento oficial precisam estar preenchidos antes da coleta final. A escala da nota ainda não foi definida; portanto, o produto deverá permitir escala comum ou escala própria por bloco, com normalização configurável quando aprovada.

O sistema deverá mostrar separadamente o valor aprovado da empresa, o resultado do exercício, o resultado da área/equipe, o score individual, os pesos, os fatores, a parcela, os descontos e o saldo não distribuído. Saldo, piso, teto e arredondamento permanecem políticas abertas e devem ser definidos antes do fechamento. Se a nota funcionar como desconto, isso deve aparecer como fator, faixa ou regra explícita, nunca como redução oculta em uma fórmula.

27. Hipóteses estratégicas

28. Componentes de decisão e BI

Centro de Visão do Grupo

A diretoria acompanha quadro, presença, pontualidade, horas extras, metas, ocorrências, tarefas, desafios, avaliações, RV e qualidade de dados. A leitura deve sempre responder: qual empresa, qual período, qual fonte, qual cobertura e qual ação possível.

Cockpit da Empresa e Unidade

O gestor acompanha o estado da operação, pessoas, tarefas, máquinas, ocorrências, riscos, prazos e pendências. O painel prioriza exceções e permite criar tarefas com descrição, resultado esperado, responsável e prazo configurável.

Centro de Jornada

RH e gestores consultam escalas, marcações, horas previstas, horas realizadas, extras, justificativas, contestações e decisões. O evento original permanece preservado, mesmo quando a decisão muda.

Centro de Confiabilidade Operacional

A operação acompanha paradas, falhas, reincidência, tempo de tratativa, causas, OS, manutenção e relação com treinamento ou processo. O foco é melhorar disponibilidade, segurança e planejamento.

Centro de Performance e Desenvolvimento

Gestores e RH acompanham avaliações, critérios, notas, evidências, planos, treinamentos, feedbacks e evolução. A plataforma não converte automaticamente uma ocorrência em nota; ela fornece contexto para decisão humana.

Centro de RV

O RH e a diretoria acompanham fundo, regras, blocos, população, scores, fatores, distribuição, saldo, exceções, aprovações e memória de cálculo.

Centro de Escuta e Ideias

A empresa recebe avaliações de clima, gestor e organização, além de sugestões. Cada entrada possui identidade definida por política, classificação, responsável, status, retorno e possibilidade de virar tarefa, melhoria ou reconhecimento.

29. Modelo de dados conceitual

30. Senior como fonte prioritária

O Senior será tratado como fonte prioritária para colaboradores, vínculos, estruturas de pessoas e marcações de ponto. O usuário informou que todos os módulos necessários estão contratados e liberados; a etapa técnica deverá confirmar credenciais, ambientes, endpoints, limites, campos e regras de segurança antes da ativação. A documentação oficial da Senior apresenta APIs de sincronização e exportação de colaboradores, além de exportação de marcações de ponto, inclusive por período.⁴ A documentação de consulta de colaboradores descreve o serviço employeejourney e autenticação por token e client_id.⁵

A plataforma deve complementar o Senior, não assumir automaticamente o papel de folha ou ponto oficial. Ela consumirá os dados necessários, preservará o ID de origem, organizará contexto operacional, conduzirá justificativas, validações, avaliações, ocorrências, indicadores e simulações de RV.

31. Demais fontes

32. Governança de dados e regras

O sistema deverá separar rascunho, validação, aprovado, congelado e reaberto com justificativa. Nenhuma alteração em regra deverá modificar silenciosamente um ciclo já congelado. A trilha deve registrar usuário, perfil, empresa, objeto, antes/depois, motivo, fonte e evidência.

A qualidade será verificada em três níveis. A entrada valida chaves, duplicidade, datas, unidade e cobertura. A regra testa metas, sentidos, pesos, faixas, prazos, arredondamentos, ausência de dados e exceções. O processo verifica segregação entre registrar, aprovar, calcular e fechar.

33. Privacidade, confiança e uso da IA

O sistema manipulará dados pessoais, de jornada, desempenho, saúde e segurança, conforme o escopo final. As finalidades, perfis, retenção, transparência e políticas deverão ser validadas com RH, Jurídico e Segurança da Informação. A pesquisa de clima poderá ser identificada, confidencial ou anônima, conforme política aprovada.

A plataforma deve impedir que telemetria ausente, divergência de ponto ou quebra de equipamento sejam convertidas automaticamente em fraude, baixa produtividade ou punição. O contexto, a qualidade do dado e o direito de resposta precisam existir antes de qualquer consequência sensível.

34. Ondas de implantação

35. Premissa de orçamento e implantação

Para fins de orçamento, considerar um esforço-base de aproximadamente 8 a 12 meses para desenvolvimento e implantação em uma empresa de referência, seguido de 3 a 4 meses adicionais por empresa para configuração, saneamento, integração, treinamento, testes e acompanhamento. Essa é uma premissa de planejamento, não uma garantia de prazo. O esforço real dependerá das APIs do Senior, da qualidade do cadastro, do número de indicadores, da participação dos donos de processo e da maturidade das demais fontes.

36. Matriz de riscos

37. Decisões ainda abertas

38. Como este documento vira produto visual

O próximo passo não deve ser começar por telas isoladas. Deve ser selecionar as jornadas prioritárias e transformá-las em experiências visuais coerentes. Cada desenho de tela deverá nascer de uma pergunta: qual trabalho a pessoa está tentando fazer, qual informação precisa para decidir e qual ação precisa executar?

39. Estrutura recomendada para cada futura tela

Cada tela deverá possuir objetivo, usuário, contexto, campos, componentes, ações, validações, estados, permissões, integrações, mensagens e navegação. O desenho visual deverá mostrar o que é informação, o que é alerta, o que é decisão e o que é ação. A futura geração das telas deve respeitar o princípio de baixa fricção no campo e a necessidade de explicabilidade em dados de avaliação e RV.

40. Próxima oficina de validação

A oficina recomendada deve reunir Rafael, diretoria, RH, Administração, Operações agrícolas, Manutenção/PCM, TI/dados e representantes de Saciatta, Ambios e Natter Administração. O objetivo será validar o mapa de empresas e unidades, revisar os JTBDs, confirmar o papel do Senior, aprovar a política inicial de WhatsApp e definir as primeiras regras da PLR anual por empresa, incluindo exercício de referência, camadas de resultado, escala, elegibilidade e políticas de saldo, piso, teto e arredondamento.

O resultado esperado da oficina é uma lista de decisões e não apenas uma apresentação. Cada decisão deve possuir descrição, resultado esperado, responsável, participantes necessários e prazo definido pelo grupo. Depois dessa validação, o documento mestre poderá gerar três artefatos derivados: o PRD do MVP, os canvases visuais finais e os desenhos das telas prioritárias.

Referências

PRD — Natter Gestão 360

Produto multiempresa de jornada, execução, desempenho e remuneração variável

1. Objetivo em uma frase

Construir uma plataforma web e móvel, com interface conversacional por WhatsApp, capaz de conectar quatro empresas independentes, seus colaboradores e unidades operacionais ao ciclo de jornada, tarefas, ocorrências, avaliações, indicadores e distribuição governada da remuneração variável.

2. Sumário executivo

O produto nasce para resolver um problema de gestão da execução. O grupo possui quatro empresas separadas, administradas pelo mesmo proprietário, e precisa enxergar cada empresa individualmente, consolidar informações e comparar indicadores compatíveis. A base recebida apresenta 732 colaboradores, 12 entidades ou unidades operacionais, 176 combinações de entidade e seção e 203 funções distintas.³

O MVP funcionará como uma camada de gestão sobre o Senior e demais fontes operacionais. O Senior será a fonte prioritária para colaboradores, vínculos, estrutura de pessoas e marcações de ponto. O usuário informou que os módulos necessários estão contratados e liberados, e que as demais fontes também possuem API ou exportação automática/controlada; o produto deverá operar com conectores oficiais, reconciliação, monitoramento e reprocessamento. A documentação oficial da Senior descreve APIs de sincronização de colaboradores, exportação de colaboradores e exportação de marcações de ponto, inclusive por período.¹ A consulta de informações de colaboradores utiliza o serviço employeejourney, com autenticação por token e client_id.²

O resultado esperado é um ciclo fechado: cadastrar e sincronizar, planejar, executar, registrar, validar, tratar desvios, avaliar, simular a remuneração variável e aprovar. A IA ajuda a fazer perguntas, cobrar pendências, resumir informações e classificar registros, mas não toma sozinha decisões que afetem remuneração, sanção ou avaliação de pessoas.

3. Contexto e motivação

As operações agrícolas, de piscicultura, frigorífico, fertilizantes/insumos e administração possuem ritmos, riscos e métricas diferentes. Na agricultura, uma mesma operação pode envolver pessoa, máquina, atividade, talhão, turno, velocidade, parada, insumo e janela agronômica. No frigorífico e na piscicultura, entram produção, qualidade, perdas, segurança, rendimento e expedição. Nas áreas corporativas, predominam prazos, conformidade, fechamento, atendimento, projetos e controles.

O Excel atual oferece uma primeira estrutura de metas e pesos, mas não é suficiente para individualizar pessoas, registrar a origem de cada dado, reconciliar ponto e operação, controlar permissões, manter histórico de regras ou explicar como um valor de RV foi formado. A planilha analisada contém quatro blocos de remuneração variável e apresenta uma referência quebrada com #REF!, além de valores derivados #REF! e #N/A no formulário.³

3.1 Problema a resolver

O sistema atual não oferece uma visão única e auditável do que estava planejado, do que foi executado, de quem executou, em que horário, com qual equipamento, qual desvio ocorreu, qual avaliação foi dada e como tudo isso afetou o cálculo da remuneração variável.

3.2 Stakeholders afetados

4. Metas do produto

Essas métricas são indicadores de sucesso do produto e não representam metas de remuneração. A linha de base deve ser medida após a seleção das fontes e da população inicial.

5. Escopo do MVP

5.1 Incluído

O MVP inclui a organização raiz do grupo, quatro empresas independentes, unidades operacionais, áreas, funções, colaboradores, gestores, máquinas, turnos e perfis de acesso. Também inclui tarefas, ocorrências, jornada, horas extras, notificações, check-ins estruturados, catálogo de indicadores, simulação da RV, avaliações básicas, escuta e trilha de auditoria.

A integração prioritária será com o Senior para pessoas, vínculos, estruturas e ponto, respeitando o contrato e as APIs disponibilizadas. Fontes agrícolas ou zootécnicas poderão entrar por importação controlada no primeiro ciclo, desde que o arquivo contenha chaves, período e responsável pela carga.

5.2 Não incluído no MVP

O MVP não substitui folha, ponto oficial, benefícios ou os módulos nativos do Senior. Não inclui decisão automática de punição, fraude, demissão ou bonificação. Não inclui diagnóstico automático de falhas de máquina, ranking definitivo de produtividade individual, integração obrigatória com todas as fontes, chatbot sem escopo ou pagamento automático da RV.

O MVP também não deve prometer comparabilidade irrestrita. Um indicador só pode ser comparado entre empresas quando a definição, unidade, período, população e qualidade do dado forem compatíveis.

6. Modelo multiempresa e permissões

6.1 Hierarquia de dados

A hierarquia obrigatória é: grupo; empresa jurídica; unidade operacional; área ou seção; cargo/função; pessoa; equipamento; ciclo; indicador; ocorrência; tarefa e evidência. Toda entidade transacional deve carregar empresa, unidade quando aplicável, período, origem e estado.

6.2 Perfis de acesso

7. Personas e casos de uso

7.1 Proprietário/diretoria

O proprietário precisa alternar entre as quatro empresas e também enxergar uma visão de portfólio. Seu principal trabalho é comparar pontualidade, metas, desafios, horas extras, ocorrências e resultados de RV, sempre com contexto e origem do dado.

7.2 RH/Administração

RH administra o cadastro, os ciclos, as comunicações e as políticas. Precisa saber quais dados chegaram do Senior, quais registros estão inconsistentes, quem precisa responder e quais regras foram utilizadas no fechamento.

7.3 Gestor e supervisor

O gestor precisa receber poucas perguntas úteis e agir sobre exceções. A tarefa deve sempre ter descrição, resultado esperado, responsável, prazo configurável, prioridade, status e evidência. O supervisor precisa operar com telas curtas em ambiente de campo.

7.4 Colaborador

O colaborador precisa de um canal simples e transparente. Deve consultar seus dados, responder solicitações, justificar horas, registrar problemas, responder pesquisas e saber quando uma informação foi aceita, devolvida ou contestada.

7.5 Comitê avaliador

O comitê utiliza os critérios de comportamento e Valores em Ação. A escala da planilha é preservada como referência: 1 não atende; 2 atende parcialmente; 3 atende; 4 supera.³ O produto deverá permitir critérios adicionais, evidências e comentários, sem transformar uma nota isolada em decisão automática.

8. User stories formais do MVP

As histórias abaixo transformam os JTBDs em unidades de valor para produto e desenvolvimento. Cada história deverá ser refinada em tarefas técnicas, testes e critérios de aceite durante o planejamento da construção. A prioridade indica valor e dependência para o MVP; não representa cronograma.

Regras transversais das user stories

Toda história que alterar pessoas, jornada, ocorrências, avaliações, regras ou PLR deve preservar origem, empresa, usuário, data/hora, estado e histórico. A IA não conclui sozinha decisões sensíveis. Nenhuma integração pode alterar um ciclo congelado. Toda ação de colaborador em canal identificado deve respeitar consentimento e finalidade; toda ação anônima deve ocultar a identidade de perfis não autorizados.

9. Especificação de telas e comportamentos

Tela 1 — Entrada e seleção de contexto

Objetivo. Autenticar o usuário e estabelecer o escopo ativo: grupo, empresa, unidade ou equipe.

Componentes. A tela exibe identificação do usuário, seletor de escopo, aviso do último acesso, atalho para ajuda e botão de entrada. O proprietário vê “Grupo” e as quatro empresas; um gestor vê somente escopos autorizados.

Validações. Usuário inativo, empresa desativada, vínculo expirado ou escopo sem permissão devem impedir a entrada naquele contexto e registrar o motivo técnico sem expor informação sensível.

Navegação. Após a entrada, o sistema conduz ao painel correspondente ao perfil. O usuário poderá trocar o contexto sem novo login, desde que permaneça dentro de seus escopos.

Tela 2 — Painel do proprietário e diretoria

Objetivo. Exibir uma visão de portfólio das quatro empresas e permitir comparações responsáveis.

Componentes. Cards de colaboradores ativos, pontualidade, tarefas no prazo, horas extras pendentes, ocorrências abertas, metas do ciclo e RV em simulação. Cada card apresenta período, fonte, última atualização e cobertura. Gráficos devem permitir alternar empresa, unidade, período e indicador.

Validações. O sistema deve bloquear comparação quando unidade de medida, periodicidade, população ou fórmula forem diferentes. Se a cobertura estiver abaixo do parâmetro configurado, o painel exibe alerta de qualidade.

Integrações. Consulta modelo operacional, indicadores, Senior, cargas operacionais e auditoria.

Tela 3 — Painel da empresa/unidade

Objetivo. Mostrar o desempenho operacional da empresa ou unidade escolhida, priorizando exceções.

Componentes. Lista de tarefas atrasadas, ocorrências abertas, horas extras sem decisão, indicadores fora da faixa, avaliações pendentes e desafios de prazo. Exibe filtros por área, gestor, equipamento, tipo de ocorrência e ciclo.

Tela 4 — Cadastro organizacional

Objetivo. Administrar a hierarquia explícita do grupo.

Componentes. Abas para empresas, unidades, áreas, funções, pessoas, gestores, centros de custo, equipamentos e turnos. A tabela mostra status, origem, última sincronização e conflitos.

Validações. Empresa e unidade devem possuir identificador único; pessoa não pode ter dois vínculos ativos incompatíveis; equipamento não pode estar simultaneamente alocado a duas unidades; toda alteração de lotação preserva histórico.

Tela 5 — Pessoas e vínculos

Objetivo. Consultar o cadastro individual e seu histórico.

Componentes. Dados básicos, empresa, unidade, função, gestor, escala, histórico de lotações, tarefas, jornada, ocorrências, avaliações, treinamentos, reconhecimentos e status de elegibilidade.

Integrações. Senior para dados de pessoa, vínculo e ponto; tarefas, ocorrências, avaliação e RV na própria plataforma.

Tela 6 — Tarefas e execução

Objetivo. Planejar e acompanhar o trabalho de equipes e áreas.

Campos obrigatórios. Descrição da tarefa; resultado esperado; responsável; empresa; unidade/área quando aplicável; prioridade; status; data de referência; prazo configurável; e origem. Evidência, equipamento, atividade e indicador são obrigatórios quando o tipo de tarefa exigir.

Estados. Rascunho; publicada; em execução; bloqueada; concluída; devolvida; cancelada; e arquivada. A mudança de estado deve registrar ator e momento.

Tela 7 — Ocorrências e equipamentos

Objetivo. Registrar e tratar quebras, paradas, riscos, danos, faltas de insumo e desvios.

Campos. Tipo; empresa; unidade; local; data/hora do evento; pessoa relacionada; equipamento; atividade; descrição; severidade; causa preliminar; fotos/áudios/documentos; ação imediata; responsável pela tratativa; prazo configurável; e impacto estimado quando autorizado.

Regra crítica. A plataforma não pode converter automaticamente ocorrência, ausência de telemetria ou divergência de ponto em culpa, fraude ou penalização.

Tela 8 — Jornada e horas extras

Objetivo. Conciliar dados do Senior com tarefas, atividades e equipamentos quando aplicável.

Componentes. Calendário/tabela de marcações; escala; horas previstas; horas realizadas; provável extra; origem; atividade relacionada; justificativa; decisão; responsável; e status de sincronização.

Validações. O evento precisa manter ID de origem, pessoa, empresa, data/hora, tipo e estado. Falhas de integração devem ser classificadas como falha de dado, não como evento negativo de pessoa.

Tela 9 — Caixa de entrada do gestor e IA

Objetivo. Organizar perguntas e pendências sem exigir navegação constante.

Componentes. Lista de solicitações; resumo diário/semanal configurável; pendências agrupadas por tema; respostas rápidas; transcrição de áudio; contexto usado; e botão de confirmação.

Regra de IA. A IA pode sugerir; o usuário confirma. O sistema deve exibir quando uma resposta foi gerada por IA e guardar o texto original, o texto interpretado e a decisão.

Tela 10 — Catálogo de indicadores e regras de RV

Objetivo. Substituir fórmulas implícitas do Excel por regras configuráveis.

Campos. Nome; definição; objetivo; empresa/escopo; área; fórmula; unidade; sentido da meta; meta; faixas; peso; bloco; periodicidade; fonte; campo de origem; responsável; evidência; elegibilidade; vigência; exceções; arredondamento; aprovadores e versão.

Validações. Peso de um bloco deve ter soma configurável; sentido da meta é obrigatório; indicador sem fonte ou responsável não pode ser publicado; mudança de regra não pode alterar ciclo congelado.

Tela 11 — Ciclo anual de PLR por empresa e simulação

Objetivo. Configurar, calcular e explicar a distribuição individual da PLR de uma empresa, com base no exercício fiscal anterior, no fechamento desse exercício e nos resultados das camadas empresa, unidade, área, equipe e indivíduo.

Componentes. Empresa; exercício fiscal de referência; status do fechamento oficial; valor aprovado da PLR; moeda; população; blocos; escala por bloco; regras; fontes; resultados da empresa; resultados de unidade/área/equipe; score individual; elegibilidade; simulação; distribuição; saldo; piso; teto; arredondamento; aprovadores; contestações e exportação.

Fluxo de cálculo. O sistema seleciona a empresa e o exercício fiscal anterior; exige confirmação do fechamento oficial; identifica a população elegível; congela a versão das regras; coleta resultados; calcula camadas organizacionais, empresariais, de unidade, área, equipe e individuais; aplica a escala configurada por bloco ou a normalização aprovada; calcula pesos ajustados; distribui a PLR; registra saldo, piso, teto e arredondamento conforme política; e apresenta a explicação individual e consolidada.

Fórmula de referência parametrizável.

O produto deve permitir que a política aprovada trate saldo não distribuído, piso individual, teto individual e arredondamento. Como essas decisões ainda estão abertas, o fechamento deve ser bloqueado enquanto os parâmetros não estiverem configurados. O desconto baseado em nota deve aparecer como fator, faixa, peso ou bloqueio identificado, nunca como uma redução oculta.

Tela 12 — Avaliação individual, comitê e desenvolvimento

Objetivo. Registrar avaliações individuais de gestor e comitê, relacionar evidências de desempenho e gerar os componentes individuais e de área/equipe que poderão participar do ciclo de PLR.

Componentes. Ciclo; empresa; área/equipe; avaliado; avaliador; critérios; escala; nota; comentário; evidência; resultado da área/equipe; plano; responsáveis; status de ciência e contestação.

Tela 13 — Escuta, clima e ideias

Objetivo. Capturar percepções dos colaboradores e garantir triagem e retorno.

Componentes. Pesquisa, tipo de identidade, perguntas, resposta, protocolo, categoria, status, responsável pela triagem e retorno.

Tela 14 — Monitor de integrações e qualidade

Objetivo. Mostrar saúde de cargas, APIs, duplicidades, faltas e reprocessamentos.

Componentes. Fonte; conector; última execução; estado; registros recebidos; aceitos; rejeitados; duplicados; pendências; tempo de processamento; erro; versão do contrato e botão de reprocessamento.

Tela 15 — Auditoria e histórico

Objetivo. Permitir reconstruir quem fez o quê, quando, em qual escopo e com qual justificativa.

Componentes. Evento; objeto; usuário; perfil; empresa; origem; antes/depois; motivo; evidência; correlação; IP/dispositivo quando autorizado; e status.

O botão Ver antes e depois compara valores; Filtrar restringe por objeto, usuário, empresa, ciclo e período; Exportar gera registro com assinatura lógica; e Reverter somente aparece para perfis autorizados e cria um novo evento, sem apagar o histórico.

9. Jornadas completas

9.1 Sincronização de pessoas e ponto com Senior

1. O administrador configura o ambiente, credenciais e escopos autorizados.
2. O sistema executa uma carga inicial ou sincronização incremental.
3. Cada colaborador recebe ID externo, empresa, unidade, vínculo, função, gestor e estado.
4. O sistema valida duplicidades, campos obrigatórios, alterações e desligamentos.
5. As marcações de ponto são recebidas com ID de origem, data/hora, tipo e colaborador.
6. O monitor apresenta aceitos, rejeitados, duplicados e falhas.
7. O administrador reconcilia totais e seleciona itens para reprocessamento.
8. O sistema grava a versão do contrato, horário da execução e responsável.

A documentação da Senior informa que há APIs para sincronização e exportação de colaboradores e para exportação de marcações, inclusive por período.¹ O usuário informou que os módulos necessários do Senior estão contratados e liberados e que as demais fontes também possuem API ou exportação automática/controlada. A implementação ainda deverá confirmar tecnicamente ambientes, credenciais, endpoints, limites, campos, chaves, versionamento e política de mudança de cada conector.

9.2 Hora extra

1. O sistema recebe marcações e escala do Senior.
2. Identifica possível extrapolação conforme regra configurada.
3. Tenta relacionar o período a tarefa, atividade, máquina ou ocorrência, quando houver dados.
4. Notifica colaborador e gestor, mostrando apenas o contexto necessário.
5. O colaborador informa motivo, atividade e evidência ou contesta o evento.
6. O gestor aprova, ajusta, contesta ou solicita complemento.
7. O sistema grava decisão e alimenta painel de jornada e, quando aplicável, simulação de RV.
8. RH acompanha pendências e exporta decisão conforme processo oficial.

9.3 Quebra ou parada de máquina

1. Evento chega de integração ou é registrado manualmente.
2. Sistema identifica equipamento, unidade, pessoa, atividade e período.
3. Supervisor confirma contexto e severidade.
4. Manutenção registra diagnóstico, OS, causa e ação corretiva.
5. Gestor acompanha prazo configurável e escalonamento.
6. Encerramento exige evidência e validação.
7. Indicadores de disponibilidade, reincidência e prazo são atualizados.
8. O evento pode alimentar desenvolvimento ou treinamento, mas não produz punição automática.

9.4 Avaliação e desenvolvimento

1. RH abre ciclo com população, critérios, avaliadores e vigência.
2. Gestor consulta histórico autorizado de entregas, tarefas, ocorrências e treinamentos.
3. Gestor atribui nota, comentário e evidência para cada critério.
4. Comitê calibra quando configurado.
5. Colaborador registra ciência, comentário ou contestação.
6. Gestor ou RH cria plano com descrição, resultado esperado, responsável e prazo configurável.
7. O sistema acompanha o plano e registra conclusão.

9.5 PLR anual por empresa

1. RH cria o ciclo para uma empresa e informa o exercício fiscal do ano anterior e a referência ao fechamento oficial.
2. RH define o valor aprovado da PLR, a população, os blocos, os pesos e as regras vigentes.
3. O sistema congela a versão dos indicadores, escalas e parâmetros do ciclo.
4. As fontes são processadas e inconsistências ficam pendentes; nenhuma ausência é convertida automaticamente em penalização.
5. Responsáveis validam resultados da empresa, unidade, área, equipe, avaliações individuais e elegibilidade.
6. O motor calcula o resultado preliminar individual, mostrando a contribuição de cada camada.
7. O painel mostra PLR da empresa, fatores, pessoas elegíveis, distribuição, saldo, piso, teto, arredondamento e exceções.
8. RH, comitê e diretoria revisam e aprovam conforme segregação de funções.
9. O ciclo é congelado e a memória individual e consolidada de cálculo é gerada.
10. A exportação autorizada leva valores, fatores e identificadores necessários ao processo oficial.
11. Qualquer reabertura produz nova versão e registra a justificativa.

10. Fluxos de dados e integrações

10.1 Contrato geral

Toda integração deve possuir identificador de origem, empresa, período, versão do contrato, timestamp, status, payload seguro, hash ou chave de idempotência, resultado de validação e responsável. Nenhum conector pode gravar diretamente em resultado congelado.

10.2 Requisitos de sincronização Senior

A sincronização deve suportar carga inicial, incremental, reprocessamento, desativação e consulta por período. O sistema deve respeitar a distinção entre evento novo, evento já consumido e reconsulta histórica. As APIs da Senior documentadas para marcações distinguem exportação de eventos ainda não consumidos e exportação por período, o que deve ser refletido no conector e nos logs.¹

A credencial deve permanecer no backend. O sistema não pode expor token, client_id, payload sensível ou CPF em logs comuns. O tratamento de falha precisa separar indisponibilidade, credencial, dado inválido, conflito de chave, limite de requisição e erro desconhecido.

11. Requisitos não funcionais

12. Critérios de aceitação do MVP

13. Roadmap de prioridades

A expansão para cada empresa deve reutilizar o núcleo comum e executar uma etapa própria de saneamento, parametrização, integração, treinamento, teste de aceitação e acompanhamento. O plano de implantação e os esforços por empresa devem ser definidos fora deste PRD.

14. Riscos e mitigações

15. Decisões confirmadas e políticas ainda abertas

16. Definição de pronto do PRD

Este PRD será considerado pronto para estimativa quando Rafael, RH, Administração, Operações, Manutenção/PCM, TI/dados e representantes das empresas validarem a hierarquia multiempresa, o escopo do MVP, os contratos técnicos dos conectores, as regras da PLR anual por empresa, a política de WhatsApp, os perfis de acesso, o tratamento de contestação e os critérios de aceitação.

A aprovação do PRD não autoriza automaticamente o pagamento de RV nem o uso de qualquer indicador como consequência trabalhista. Ela autoriza a construção e o teste controlado do produto dentro da governança definida pelo grupo.

Referências

Modelo de negócio e dados — Natter Gestão 360

Premissas confirmadas

As quatro empresas são individualmente separadas e serão operadas na mesma plataforma. O proprietário terá acesso de portfólio, podendo consultar cada empresa isoladamente ou comparar indicadores compatíveis entre elas. A unidade operacional da planilha deve ser vinculada explicitamente a uma empresa jurídica no cadastro mestre.

O Senior será a fonte prioritária de pessoas, vínculos e ponto, conforme os módulos contratados e as APIs liberadas no ambiente do grupo. A documentação oficial da Senior apresenta APIs para importação/exportação no contexto do HCM, incluindo sincronização de colaboradores e exportação de marcações por período.⁴ A documentação de consulta de colaboradores também apresenta o serviço employeejourney e autenticação por bearer token e client_id.⁵

A remuneração variável será tratada como PLR anual por empresa, distribuída individualmente entre pessoas elegíveis conforme resultados do exercício fiscal anterior, notas, pesos, regras dos blocos e critérios aprovados. O valor de R$ 10 milhões foi apenas um exemplo de modelagem e não deve aparecer como valor oficial pré-configurado.

Modelo de tenancy e escopo

A plataforma terá uma organização raiz do grupo, quatro empresas jurídicas filhas e as unidades operacionais vinculadas. Um usuário poderá possuir um ou mais escopos de acesso. O escopo deve estar presente em toda consulta, exportação, aprovação, cálculo e auditoria.

Perfil de proprietário e comparativos

O proprietário terá uma visão de portfólio com seletor de empresa, unidade e período. A comparação só poderá ser ativada quando os indicadores tiverem a mesma definição, unidade de medida, periodicidade e cobertura. O painel deve mostrar a qualidade dos dados e não exibir um ranking sem contexto.

As comparações iniciais podem contemplar pontualidade, percentual de tarefas concluídas, cumprimento de metas, horas extras, tempo de tratativa e desafios em aberto. Indicadores de produtividade de máquinas e operações agrícolas deverão permanecer contextualizados por cultura, operação, equipamento e condição de campo.

Integração Senior

A integração terá dois fluxos. No fluxo de entrada, o Natter Gestão 360 importa ou sincroniza pessoas, gestores, empresas, unidades, cargos, funções, escalas, horários e demais campos disponíveis. No fluxo de saída ou consulta, consome marcações de ponto e informações necessárias para detectar horas extras e alimentar o fluxo de justificativa.

A documentação oficial da Senior informa endpoints como employeesSync, EmployeesExport, ClockingEventExport e ClockingEventExportByPeriod, além de mecanismos de importação via arquivo/CSV no HCM.⁴ A disponibilidade exata deve ser validada no contrato e no ambiente do cliente, pois a própria documentação alerta que APIs privadas podem mudar sem aviso.⁴

PLR anual por empresa

Cada empresa terá seu próprio ciclo de PLR, com valor aprovado, população elegível, regras de resultado e regra de alocação. A diretoria poderá visualizar e consolidar os ciclos, mas o cálculo e a aprovação permanecem identificados por empresa. O ciclo referencia o exercício fiscal do ano anterior e o fechamento oficial desse exercício.

Fórmula configurável de referência

O sistema deverá permitir uma fórmula de referência, sem fixá-la como regra legal ou definitiva:

Se o modelo de negócio for “descontar do fundo com base nas notas”, o produto deve apresentar o desconto como fator explícito. Por exemplo, uma nota abaixo da meta pode reduzir o score individual, o fator da empresa ou ambos, conforme a regra aprovada. O sistema não deve esconder o desconto em uma fórmula opaca.

Estados do ciclo de PLR

O ciclo deverá passar por: rascunho; configuração; coleta de dados; cálculo preliminar; validação das áreas; calibração; aprovação; congelamento; exportação; e reabertura excepcional. Cada transição terá responsável, data, comentário e evidência.

Decisões ainda necessárias

O PRD deve deixar parametrizáveis as seguintes decisões: valor aprovado por empresa; escala comum ou escala própria por bloco; eventual normalização; tratamento de admissões, desligamentos, afastamentos, transferências e mudanças de função; uso de ocorrência na PLR; piso, teto, saldo não distribuído e arredondamento. O gestor inicia ou informa movimentações e o RH operacionaliza o fluxo, preservando a vigência histórica.

Referências externas

Premissas atualizadas — PLR, integrações e governança do Natter Gestão 360

Decisões confirmadas

Pontos ainda abertos, que não devem ser inventados

Modelo funcional revisado de PLR

Cada empresa possui um ciclo próprio de PLR, com possibilidade de visão consolidada pela diretoria. O ciclo referencia o exercício fiscal encerrado do ano anterior e deve possuir estados de configuração, coleta, validação, simulação, aprovação, congelamento, comunicação e exportação.

A distribuição é individual por colaborador, mas o cálculo pode ser composto por camadas de empresa, unidade, área, equipe e indivíduo. A arquitetura recomendada é:

A existência de uma área no cálculo não deve esconder o resultado individual. O sistema deve apresentar a contribuição de cada camada e a memória de cálculo da pessoa.

Política inicial de WhatsApp

Antes de habilitar ações transacionais, o produto deverá publicar uma política que defina finalidade, consentimento, identificação do usuário, tipos de mensagem, retenção do histórico, uso de áudio e transcrição, tratamento de dados sensíveis, opt-out, escalonamento para atendimento humano, contestação e auditoria. O WhatsApp poderá começar como canal de notificações, perguntas e respostas estruturadas; aprovação de hora extra, alteração de cadastro ou decisão de PLR só poderá ocorrer quando houver autenticação, confirmação e trilha suficientes.

Integrações

O Senior será a fonte prioritária de colaboradores, vínculos, estruturas de pessoas e ponto. As demais integrações deverão ser tratadas como conectores de primeira classe, inclusive ERP Senior, Solinftec, GATC, Multi Bovinos, Milvus e John Deere Operations Center. Para cada fonte, o sistema deve armazenar identificador de origem, versão do contrato, data de coleta, status, contagem recebida, contagem processada, rejeições, reprocessamentos e reconciliação.

Consequência para o PRD

O PRD deve ser atualizado para substituir a hipótese de fundo global de R$ 10 milhões por PLR configurável por empresa e por ciclo fiscal, manter o cálculo individual, incorporar camadas de resultado da área e formalizar as políticas abertas como configurações obrigatórias antes do fechamento. As histórias de usuário devem refletir esse modelo.